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Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) 
Abstract 


The DNS Security Extensions (DNSSEC) were developed to provide origin 
authentication and integrity protection for DNS data by using digital 
signatures. These digital signatures can be verified by building a 
chain of trust starting from a trust anchor and proceeding down to a 
particular node in the DNS. This document specifies two different 
ways for validating resolvers to signal to a server which keys are 
referenced in their chain of trust. The data from such signaling 
allow zone administrators to monitor the progress of rollovers ina 
DNSSEC-signed zone. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8145. 
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Copyright Notice 


Copyright (c) 2017 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


The DNS Security Extensions (DNSSEC) [RFC4033] [RFC4034] [RFC4035] 
were developed to provide origin authentication and integrity 
protection for DNS data by using digital signatures. DNSSEC uses 

Key Tags to efficiently match signatures to the keys from which they 
are generated. The Key Tag is a 16-bit value computed from the RDATA 
portion of a DNSKEY resource record (RR) using a formula not unlike a 
ones-complement checksum. RRSIG RRs contain a Key Tag field whose 
value is equal to the Key Tag of the DNSKEY RR that validates the 
signature. 


Likewise, Delegation Signer (DS) RRs also contain a Key Tag field 
whose value is equal to the Key Tag of the DNSKEY RR to which it 
refers. 


This document specifies how validating resolvers can tell a server, 
in a DNS query, which DNSSEC key(s) they would use to validate the 
server’s responses. It describes two independent methods for 
conveying Key Tag information between clients and servers: 


1. placing an EDNS option in the OPT RR [RFC6891] that contains the 
Key Tags (described in Section 4) 


2. periodically sending special "Key Tag queries" to a server 
authoritative for the zone (described in Section 5) 


Each of these new signaling mechanisms is OPTIONAL to implement and 
use. These mechanisms serve to measure the acceptance and use of new 
DNSSEC trust anchors and key signing keys (KSKs). This signaling 
data can be used by zone administrators as a gauge to measure the 
successful deployment of new keys. This is of particular interest 
for the DNS root zone in the event of key and/or algorithm rollovers 
that rely on [RFC5011] to automatically update a validating DNS 
resolver’s trust anchor. 


This document does not introduce new processes for rolling keys or 
updating trust anchors. Rather, it specifies a means by which a DNS 
query can signal the set of keys that a client uses for DNSSEC 
validation. 
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1.1. Design Evolution 


Initially, when the work on this document started, it proposed 
including Key Tag values in a new EDNS(0) option code. It was 
modeled after [RFC6975], which provides DNSSEC algorithm signaling. 


The authors received feedback from participants in the DNSOP Working 
Group that it might be better to convey Key Tags in the QNAME of a 
separate DNS query, rather than as an EDNS(0) option. Mostly, this 
is because forwarding (e.g., from stub to recursive to authoritative) 
could be problematic. Reasons include the following: 


1. EDNS(0) is a hop-by-hop protocol. Unknown option codes would not 
be forwarded by default, as per [RFC6891]. 


2. Middleboxes might block entire queries containing unknown EDNS (0) 
option codes. 


3. A recursive resolver might need to remember Key Tag values (i.e., 
keep state) received from its stub clients and then forward them 
at a later opportunity. 


One advantage of the EDNS(0) option code is that it is possible to 
see that a stub client has a different Key Tag list than its 
forwarder. In the ONAME-based approach, this is not possible because 
queries originated by a stub and a forwarder are indistinguishable. 
The authors feel that this advantage is not sufficient to justify the 
EDNS (0) approach. 


One downside to the QNAME approach is that it uses a separate query, 
whereas with EDNS(0) the Key Tag values are "piggybacked" onto an 
existing DNSKEY query. For this reason, this document recommends 
only sending QNAME-based Key Tag queries for trust anchors, although 
EDNS-based Key Tags can be sent with any DNSKEY query. 


Another downside to the ONAME-based approach is that since the 

trust anchor zone might not contain labels matching the QNAME, these 

queries could be subject to aggressive negative caching features now 

in development by the Working Group. This could affect the amount of 
signaling sent by some clients compared to others. 


A probably minor downside to the QNAME-based approach is that it 
cannot be used with extremely long query names if the addition of the 
prefix would cause the name to be longer than 255 octets. 
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2. Requirements Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Terminology 


Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. 
A validating security-aware resolver uses this public key or hash 
as a starting point for building the authentication chain to a 
signed DNS response. In general, a validating resolver will have 
to obtain the initial values of its trust anchors via some secure 
or trusted means outside the DNS protocol. Presence of a 
trust anchor also implies that the resolver should expect the zone 
to which the trust anchor points to be signed. (This paragraph is 
quoted from Section 2 of [RFC4033].) 


Key Tag: A 16-bit integer that identifies and enables efficient 
selection of DNSSEC public keys. A Key Tag value can be computed 
over the RDATA of a DNSKEY RR. The Key Tag field in the RRSIG and 
DS records can be used to help select the corresponding DNSKEY RR 
efficiently when more than one candidate DNSKEY RR is available. 
For most algorithms, the Key Tag is a simple 16-bit modular sum of 
the DNSKEY RDATA. See [RFC4034], Appendix B. 


4. Using the edns-key-tag Option 
4.1. Option Format 
The edns-key-tag option is encoded as follows: 


0 8 16 
4--+--4+--4--4--4--4--4--4--+--4--4--4+--+--4+--4+--+ 
| OPTION-CODE | 
4--+--4+--4--4--4--4--4--4--4--4--4--4--+--4+--4+--+ 
| OPTION-LENGTH | 
4--+--4+--4--4--4--4--4--4--4+--4--4--4--+--4--4+--+ 
| KEY-TAG | 
4--+--4+--4--4--4--4--4--4--4--4--4--4+--+--4--4+--+ 
| O / 


E 
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where: 


OPTION-CODE: The EDNSO option code assigned to edns-key-tag (14). 


OPTION-LENGTH: The value 2 x number of key-tag values present. 
KEY-TAG: One or more 16-bit Key Tag values ([RFC4034], Appendix B). 
4.2. Use by Queriers 


A validating resolver sets the edns-key-tag option in the OPT RR when 
sending a DNSKEY query. The validating resolver SHOULD also set the 
DNSSEC OK bit (also known as the DO bit) [RFC4035] to indicate that 
it wishes to receive DNSSEC RRs in the response. 


A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY 
queries. 


The KEY-TAG value(s) included in the edns-key-tag option represents 
the Key Tag of the trust anchor or DNSKEY RR that will be used to 
validate the expected response. When the client sends a DNSKEY 
query, the edns-key-tag option represents the Key Tag(s) of the 
KSK(s) of the zone for which the server is authoritative. A 
validating resolver learns the Key Tag(s) of the KSK(s) from the 
zone’s DS record(s) (found in the parent) or from a trust anchor. 


A DNS client SHOULD include the edns-key-tag option when issuing a 
DNSKEY query for a zone corresponding to a trust anchor. 


A DNS client MAY include the edns-key-tag option when issuing a 
DNSKEY query for a non-trust anchor zone (i.e., Key Tags learned via 
DS records). Since some DNSSEC validators implement bottom-up 
validation, a non-trust anchor Key Tags zone might not be known at 
the time of the query. Such a validator can include the edns-key-tag 
option based on previously cached data. 


A DNS client MUST NOT include Key Tag(s) for keys that are not 
learned via either a trust anchor or DS records. 


Since the edns-key-tag option is only set in the query, if a client 


sees these options in the response, no action needs to be taken and 
the client MUST ignore the option values. 
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4.2.1. Stub Resolvers 


Typically, stub resolvers rely on an upstream recursive resolver (or 
cache) to provide a response. Optimal setting of the edns-key-tag 
option depends on whether the stub resolver elects to perform its own 
validation. 


4.2.1.1. Validating Stub Resolvers 
A validating stub resolver sets the DNSSEC OK bit [RFC4035] to 
indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG 
RRs) in the response. Such validating resolvers SHOULD include the 
edns-key-tag option in the OPT RR when sending a DNSKEY query. 
4.2.1.2. Non-validating Stub Resolvers 


The edns-key-tag option MUST NOT be included by non-validating stub 
resolvers. 


4.2.2. Recursive Resolvers 
4.2.2.1. Validating Recursive Resolvers 
A validating recursive resolver is, by definition, configured with at 


least one trust anchor. Thus, a recursive resolver SHOULD include 
the edns-key-tag option in its DNSKEY queries as described above. 


In addition, the clients of a validating recursive resolver might be 
configured to do their own validation, with their own 

trust anchor(s). When a validating recursive resolver receives a 
query that includes the edns-key-tag option with a Key Tag list that 
differs from its own, it SHOULD forward both the client's Key Tag 
list and its own list. When doing so, the recursive resolver SHOULD 
transmit the two Key Tag lists using separate instances of the 
edns-key-tag option code in the OPT RR. For example, if the 
recursive resolver's Key Tag list is (19036, 12345) and the 
stub/client’s list is (19036, 34567), the recursive resolver 

would include the edns-key-tag option twice: once with values 
(19036, 12345) and once with values (19036, 34567). 


A validating recursive resolver MAY combine stub/client Key Tag 
values from multiple incoming queries into a single outgoing query. 
It is RECOMMENDED that implementations place reasonable limits on the 
number of Key Tags to include in the outgoing edns-key-tag option. 
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If the client included the DNSSEC OK and Checking Disabled (CD) bits 
but did not include the edns-key-tag option in the query, the 
validating recursive resolver MAY include the option with its own 
Key Tag values in full. 


Validating recursive resolvers MUST NOT set the edns-key-tag option 
in the final response to the stub client. 


4.2.2.2. Non-validating Recursive Resolvers 


4. 


5. 


3% 


Recursive resolvers that do not validate responses SHOULD copy the 
edns-key-tag option seen in received queries, as they represent the 
wishes of the validating downstream resolver that issued the original 
query. 


3. Use by Responders 
An authoritative name server receiving queries with the edns-key-tag 
option MAY log or otherwise collect the Key Tag values to provide 


information to the zone operator. 


A responder MUST NOT include the edns-key-tag option in any DNS 
response. 


Using the Key Tag Query 
1. Query Format 


A Key Tag query consists of a standard DNS query of type NULL and of 
class IN [RFC1035]. 


The first component of the query name is the string "_ta-" followed 
by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag 
values. The zone name corresponding to the trust anchor is appended 


to this first component. 


For example, a validating DNS resolver that has a single root zone 
trust anchor with Key Tag 17476 (decimal) would originate a query of 
the form OTYPE=NULL, OCLASS=IN, ONAME=_ta-4444. 


Hexadecimal values MUST be zero-padded to four hexadecimal digits. 
For example, if the Key Tag is 999 (decimal), it is represented in 
hexadecimal as 03e7. 
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When representing multiple Key Tag values, they MUST be sorted in 
order from smallest to largest. For example, a validating DNS 
resolver that has three trust anchors for the example.com zone with 
Key Tags 1589, 43547, 31406 (decimal) would originate a query of the 
form QTYPE=NULL, QCLASS=IN, QNAME= _ta-0635-7aae-aalb.example.com. 


5.2. Use by Queriers 


A validating DNS resolver (stub or recursive) SHOULD originate a 

Key Tag query whenever it also originates a DNSKEY query for a 

trust anchor zone. In other words, the need to issue a DNSKEY query 
is also the trigger to issue a Key Tag query. 


The value(s) included in the Key Tag query represents the Key Tag(s) 
of the trust anchor that will be used to validate the expected DNSKEY 
response. 


A validating DNS resolver SHOULD NOT originate Key Tag queries when 
also originating DNSKEY queries for non-trust anchor zones. 


A non-validating DNS resolver MUST NOT originate Key Tag queries. 


DNS resolvers with caches SHOULD cache and reuse the response to a 
Key Tag query just as it would any other response. 


5.3. Use by Responders 


An authoritative name server receiving Key Tag queries MAY log or 
otherwise collect the Key Tag values to provide information to the 
zone operator. 


An authoritative name server MUST generate an appropriate response to 
the Key Tag query. A server does not need to have built-in logic 
that determines the response to Key Tag queries: the response code is 
determined by whether the data is in the zone file or covered by 
wildcards. The zone operator might want to add specific Key Tag 
records to its zone, perhaps with specific TTLs, to affect the 
frequency of Key Tag queries from clients. 


5.3.1. Interaction with Aggressive Negative Caching 


Aggressive NSEC/NSEC3 negative caching [NSEC-NSEC3-Usage] may also 
affect the quality of Key Tag signaling. When the response code for 
a Key Tag query is NXDOMAIN, DNS resolvers that implement aggressive 
negative caching will send fewer Key Tag queries than resolvers that 
do not implement it. 
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For this reason, zone operators might choose to create records 
corresponding to expected Key Tag queries. During a rollover from 
Key Tag 1111 (hex) to Key Tag 2222 (hex), the zone could include the 
following records: 


ta 1111 IN NULL \# 0 
_ta-2222 IN NULL \# 0 
_ta-1111-2222 IN NULL \# 0 


Recall that when multiple Key Tags are present, the originating 
client MUST sort them from smallest to largest in the query name. 


6. IANA Considerations 


IANA has assigned an EDNSO option code for the edns-key-tag option in 
the "DNS EDNSO Option Codes (OPT)" registry as follows: 


Ho $ $ $ + 

| Value | Name | Status | Reference | 

Ho Sans cic nati aii 4 == S === =E= $ + 

| 14 | edns-key-tag | Optional | RFC 8145 | 

Ho di Ni Ho $ + 
7. Security Considerations 


This document specifies two ways for a client to signal its 

trust anchor knowledge to a cache or server. The goal of these 
optional mechanisms is to signal new trust anchor uptake in clients 
to allow zone administrators to know when it is possible to complete 
a key rollover in a DNSSEC-signed zone. 


There is a possibility that an eavesdropper or server could infer the 
validator in use by a client by the Key Tag list seen. This may 
allow an attacker to find validators using old, possibly broken, 
keys. It could also be used to identify the validator or to narrow 
down the possible validator implementations in use by a client; the 
validator used by the client could have a known vulnerability that 
could be exploited by the attacker. 


Consumers of data collected from the mechanisms described in this 
document are advised that provided Key Tag values might be "made up" 
by some DNS clients with malicious, or at least mischievous, 
intentions. For example, an attacker with sufficient resources might 
try to generate large numbers of queries including only old Key Tag 
values, with the intention of delaying the completion of a key 
rollover. 
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DNSSEC does not require keys in a zone to have unique Key Tags. 
During a rollover, there is a small possibility that an old key anda 
new key will have identical Key Tag values. Zone operators relying 
on the edns-key-tag mechanism SHOULD take care to ensure that new 
keys have unique Key Tag values. 


8. Privacy Considerations 


This proposal provides additional, optional "signaling" to DNS 
queries in the form of Key Tag values. While Key Tag values 
themselves are not considered private information, it may be possible 
for an eavesdropper to use Key Tag values as a fingerprinting 
technique to identify particular validating DNS clients. This may be 
especially true if the validator is configured with trust anchors for 
zones in addition to the root zone. 


A validating resolver need not transmit the Key Tags in every 
applicable query. Due to privacy concerns, such a resolver MAY 
choose to transmit the Key Tags for a subset of queries (e.g., every 
25th time) or by random chance with a certain probability (e.g., 5%). 


Implementations of this specification MAY be administratively 
configured to only transmit the Key Tags for certain zones. For 
example, the software’s configuration file may specify a list of 
zones for which the use of the mechanisms described here is allowed 
or denied. Since the primary motivation for this specification is to 
provide operational measurement data for root zone key rollovers, it 
is RECOMMENDED that implementations at least include the edns-key-tag 
option for root zone DNSKEY queries. 
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